perm filename STEVE.LE1[ESS,JMC] blob sn#043804 filedate 1973-05-18 generic text, type C, neo UTF8
COMMENT āŠ—   VALID 00002 PAGES
C REC  PAGE   DESCRIPTION
C00001 00001
C00002 00002	FOONLY AS A NETWORK RESOURCE
C00018 ENDMK
CāŠ—;
FOONLY AS A NETWORK RESOURCE

	In accordance with our discussion on  Monday and a discussion
with  Larry  on  Thursday,    I  have  prepared  this  memorandum  on
converting Foonly into  a network  resource.  Three  variants of  the
plan cost $340,000, $700,000, and $1,000,000 respectively.

	1.  Larry  has told  me  some  things  about the  results  of
various   improvements  in  NCP  programs  that   give  me  a  higher
subjective probability that  operating displays over the  network can
be done  without serious degredation  of performance.   Therefore,  I
propose the  following  experiment  in connection  with  Foonly.    A
PDP-11/45 be  procured  and attached  to our  IMP using  commercially
available hardware.  I  don't yet know who makes it or what it costs,
but it  is  not  excessive.   The  Datadisc display  system  and  the
keyboard  multiplexer will  then  be  attached to  the  PDP-11.   The
PDP-11  will be attachable  either to  the IMP or  the PDP-10 IO-bus.
(An alternative  is to make  the display  processor and the  keyboard
multiplexor pluggable to  either the PDP-11 or the  PDP-10).  In this
way, we can debug  a system where the  displays are connected to  the
PDP-10 and later to  Foonly through the net. When  they are connected
to  the net,   other network  computers are then  directly accessible
from the display system.  At some point, I would like to  replace the
Datadisc by ic-memory  so we can get the arbitrary  character set and
other  flexibility that I  advocate for the  standard display system.
If it  all works the  network will  then become  the standard way  of
using our machine just as you  propose.  I have a good person in mind
to work on this,  but it will  be necessary to  replace him on  other
tasks.  

	2. We will  put two people on  getting TENEX ready to  run on
Foonly.   We  anticipate  having to  improve TENEX  in  the following
respects: it must run efficiently  with about 100 users (our  present
system runs  with 50),   it  must run efficiently  with a  large file
system  (at present  TENEX requires a  disk audit  after every system
crash which would be  prohibitive), TENEX must support displays  in a
way that  is not just  an imitation of  a teletype (this  is required
whether the  displays  run  over  the network  or  not),  TENEX  must
support our  special hardware,   and finally  TENEX must support  the
user  microcode provided  by Foonly.   All these  things can  be done
within TENEX and we may  be able to get BBN  to do some of them.   We
will take part in the TENEX user group activity.

	It  will  also be  necessary  to  do  some software  to  take
advantage  of the fact  that Foonly  allows 23 bit  addresses in some
contexts.  This  was put in at  the instigation of the  PLANNER, etc.
people.    One  of the  major  attractions  of  Foonly as  a  network
resource will be this large addressing space.

	3.  In  order to  be a proper  resource,   Foonly needs  more
memory.    Because  the  64K D.E.C.    memory  dating  from  1966  is
unreliable and diffficult  to interface, I propose including at least
128K of  additional  memory  in  the  initial plan.    However,    if
substantial network use  develops, I think that 512K to  1024K can be
added  and will  be cost-effective to  ARPA,   because Foonly's speed
will get more  computation per memory  dollar than would putting  the
memory on a slower machine.

	There are  several schemes for adding memory  to Foonly.  One
is to buy  it with  interface from Ampex  or Systems  Concepts.   The
Systems Concepts memory scheme is quite  expensive, but, according to
Larry, has features  that may recommend it in the Foonly case as well
as for Illiac.  Another plan is to duplicate our present interface.

	4.  Our present  swapper is the  ancient Librascope.  It  has
only  5,000,000 of  its original  12,000,000  words left  and it  may
break  down irrevocably at some time.  The  way we use it now, it can
support about 56 users.  To support 100 users many  of whom will have
large programs  will require  a bigger faster  swapper or the  use of
secondary swapping to the  3330.  We don't  have a proposal for  this
yet.

	5. We also propose to  get a manager for the project.   It is
possible  that Ralph  Gorin may be  suitable or  we may have  to hire
someone from the outside.  When the system is serving  network users,
we will need at least one person  whose main job will be dealing with
outside  users,  and a manager who  controls the facility well enough
to be sure that it serves the outside users well.

	6.  There are two  plans for debugging Foonly.  The  old plan
calls  for integrating Foonly  into the  present system  with minimal
disturbance  and  minimal  cost.    It  is  described  in  the   file
PLAN[F,DWP] in our system.

	7. The second plan is cleaner,  and  is designed to produce a
Foonly  system with all new  hardware and involves  no disturbance to
our present system.  It is more expensive.

	The plan starts  by connecting the  bare Foonly processor  to
the  PDP-10.   In this  connection  Foonly is  an I-O  device to  the
PDP-10   and  the   PDP-10  can   control  Foonly   while  continuing
time-sharing.  To Foonly, the PDP-10 is the console  computer and has
access to the  internal registers and timing chains  of Foonly.  This
will permit Foonly to be debugged expeditiously.  In my opinion,  the
development of this method of  debugging complicated digital hardware
is  a sufficient scientific  justification for  completing the Foonly
project.  It also works in the first plan.

	When the processor is debugged,  separate memory  is attached
to Foonly using a  new memory buss.  It is believe  that the buss can
be purchased with the memory, for example, from Systems Concepts.

	Next a  new swapping device, a new rented 3330, and the third
port on the IMP are  attached and TENEX is debugged.  At  this point,
the network users can be allowed on.

	Finally, the  Stanford special I-O devices  are attached, the
3330 on the PDP-10 goes off rental, and the 128K Ampex memory on  the
PDP-10  is switched  over  to  Foonly.   The  PDP-10 remains  as  the
console  computer of  Foonly and  is usable for  other purposes  in a
limited way.

	It is estimated  that this scheme will  take two more  months
to complete than the first scheme, although the time may be saved.

BUDGET

	The short  time available for completing  this memorandum did
not  permit  precise  estimates  of  costs.    I  think  the  present
estimates err on the generous side but not by much.

	1.   The  minimal  plan described  orally  on Monday  and  in
written  form as  FOO73A[ESS,JMC] on  our system  costs  $240,000 for
hardware and personnel  assuming D.E.C.  gives the  $67,500 worth  of
parts and services they have offered.  As  you recall, this offer has
some conditions attached to it that need to be negotiated.

	2.    I estimate  the  PDP-11/45 for  networking  the display
system  at $26,000.    Upgrading  the  display  system  to  arbitrary
characters and flexible  graphics would cost another  $75,000 if this
were  to  be  done at  this  time.   Six  man  months  of programming
associated with this task will cost another $10,000.

	3.  System  Concepts quotes $128,000  as a maximum price  for
supplying  and   additional   128K  of  core   interfaced  to  Foonly
specifications.  Full network service  will require at least 512K  of
core.  It  is hard to believe  we would have  to pay $1 per  word for
this even fully interfaced. Let us guess $320,000 for this variant.

	4.   A  new swapper  might cost  $200,000,   but this  is the
weakest estimate, because  we don't know  much about  what is on  the
market, and  it is hard to  estimate how much will  be required since
it will depend on what size jobs the users choose to run.

	5. We  are presently paying IBM about $5000 per month in disk
rental,    and  we  estimate  that  network  use   might  cause  this
requirement  to double,  but there  will probably  be  something even
more cost-effective  than the  3330 in  a couple  of years.   If  the
Datacomputer is reliable and if good transfer  rates can be obtained,
we might be able to reduce our local storage requirements.

	6. The  plan for providing Foonly with  all new hardware will
probably cost  another  $50,000  in parts  for  a new  I-O  buss  and
another $10,000 in engineering time to implement.

	7. We estimate  another 3 man years  for software development
costing $75,000 with overhead.

	Thus we have the following costs:

1.  Minimal plan -  Foonly in  present Stanford system  with 128K new
core with copy of  present interface $340,000 (ARPA's  exposure would
be  only $240,000  if  the new  core  were purchased  only after  the
hardware worked).

2.   Foonly  in  present  system  with  displays  on  IMP  and  TENEX
implemented in  parallel with  hardware completion.   128K of  memory
from Systems Concepts. 	$700,000

3.  Foonly with all  new hardware operating  on 512K of  new memory -
Displays upgraded  to  proposed network  standard -  $1,000,000.  For
this we get the equivalent of 10 PDP-10s.

	I  have deliberately  rounded  the numbers  in  the last  two
variants in order to emphasize the approximateness of the costs.

	I note  that I have not got the personnel costs at all right,
because of including  overhead in some  estimates and omitting it  in
others.  Les will have the honor of fixing it.

	The  system  once running  will  require  about three  people
beyond our  normal staff  for making  it fully  useful as  a  network
resource.